One of the chief complaints among software users is the lack of consistent product documentation that directly and clearly addresses user problems and questions. Often, product documentation is presented with inconsistent structure and styles, is not integrated into a user's overall experience with a product (for example, the documentation does not consider what is already obvious because of the user interface design or other information shown in messages), and focuses on describing what a user sees in the user interface rather than why or how that information is derived so that the user can act on it. For example, product documentation is more likely to describe the physical appearance and axes of a graph on a page than to explain how the financial information in that graph was calculated.
One reason that product documentation sometimes is ineffective has partly to do with the fact that technical writers often do not have easy access to the same innovative design methodologies and architectures that are used by software engineers and user interface designers. Technical writers rely instead on corporate-wide or industry-standard style guides that are geared toward applying correct English grammar, style, and usage. The Chicago Manual of Style is an example of such a style guide. However, these style guides do not address how best to organize and structure documentation from the point of view of the user experience of the product. Style guides generally assume that documentation is organized into traditional computer manual types, such as user guides, administrator guides, and implementation guides. Because of their broad audience, these style guides also fail to consider the specific tools that technical writers must use to create the documentation, such as Microsoft Word, PTC Arbortext® Editor, or Adobe Framemaker. Thus, technical writers are forced to loosely interpret these generic style guides and imitate the inconsistently applied practices of their peers.